home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
rbbs_pc
/
mapl0301.zip
/
RBBSCHAT.DOC
< prev
next >
Wrap
Text File
|
1992-07-05
|
10KB
|
192 lines
RBBS-PC Internode chat modifications Release 3.00 August 28 1990
Copyright 1989-1990 by John Morris All Rights Reserved.
Written By:
John Morris
TradeWars Software
I can be reached on my BBS:
The Reno RBBS
(702)746-1358 Voice (limited hours)
(702)746-1364 Strictly V32
(702)746-1365 USR-HST
NOTE:
Modified RCHAT300.BAS/RCHAT300.STB files to be used with MAple version
ONLY )included in RBBS-MPL.ZIP file
CHAT.MNU chat help, a menu list of chat commands.
This code is intended to be compiled with QuickBASIC 3.0 or later, mainly
because I make generous use of block IF..END IF statements. I also don't
use a whole lot in the way of line-numbers, which means I use quite a few
DO..LOOP statements.
This will one of many releases of this code, and it is my third release
of my internode chat code. I wanted the ability of the user to page another,
and I also wanted to see if I could emulate a 'True chat'.
NOTE: True Chat removed in Maple version to save code !!
I do realize that
there are quite a few chat products out there in BBS-land, but none follows
the RBBS tradition of including source code, which means that they have to be
implemented as doors.
My logic is that if a system is popular enough to have multiple nodes, it has
a good file & message bases (doors are generally secondary in multi-node
systems) So, why should a guy have to open a door? Just my humble opinion.
So anyways, here is the code for you to play with.
You are free to modify the code for implementation in your system, but you
may not distribute this code in modified form! If you'd like to see your
mods incorporated into the official release of this mod, then give me a
jingle, and I'll happy to talk with you about your mods.
How its -supposed- to work
--------------------------
This mod will give your users access to 2 new commands. Rather than message
around with CONFIG I decided all 'options' will have to be hard-coded, which
means these commands are hard-coded. The commands are: CHAT and @
(The '@' is for turbo-key users) you can, of course, change these to
whatever you like (they are found in R-PCCHAT.MRG). For the first couple
o' releases I made 2 separate ways to chat. Starting with 3.00 there is one
chat routine, that will function like two. All chats are character by
character. Each node uses a 72 byte ring-buffer to hold the typed text.
(Thanks go out to Cary Kolker for help on the ring buffer!) Because each
character typed by each node must be saved to disk, there is always the
possibility of things going wrong. Thats the main reasoning behind the
ring-buffer. For best performance, and to save where and tear on your
hard disk, I suggest modifying RCHAT300.BAT where it says:
NOTE:
STOCK RCHAT300 was CONST ChatFileName$ = "RBBSCHAT.DEF"
Maple mods use CONFIG to set this Drive !!!
Change that to a RAM drive. For instance, if your RAM drive was drive H,
you'd change it to:
CONST ChatFileName$ = "H:RBBSCHAT.DEF"
The chat mod also uses shared files with record locking. This means you need
to have SHARE loaded on each node running the chat mods. (you can find
SHARE.EXE on your DOS disk) RBBSCHAT.DEF is opened in SHARED mode, with
read & write access (nobody is denied access). A record will be locked
immediately prior to a read or write operation. It will be unlocked
right after the read/write operation. This does not operate in the same
manner as RBBS-PC itself! I fully realize this. I don't think the chat
would work at all using the same file locking methods as RBBS, so I did
not try to use the RBBS methods. I may be wrong, and I realize that.
As long as most folks are using DOS 3.1 or above, we might as well make use
of its abilities.
NOTE: DesQview routine ARE supported !
RBBS-VAR.MOD. Incuded with Maple merges!
All mods are commented with 'CHATxxxx' (where xxxx is the date) starting
at column 70.
Update History:
---------------
02/14/90 First bungled release.. forgot to put CHATHELP into the ZIP
1.00 file I uploaded to a couple places. Fixed that on my system,
but a lot of guys missed it.
03/22/90 Second release. Went and added some improvements, and implemented
2.00 some of Tom Macks ideas for internode chat. These include
a way for each user to 'lock-out' a page attempt from other
nodes. This allows them to roam in privacy. The option is toggled
from the (where else?) T)oggle options prompt.
Thanks go out to Cary Kolker for doing something very similar to
what I was planning for the TrueCh@. Basically to keep some
systems from dropping chars here-and-there, Cary implemented
the TrueCh@ in a 'ring buffer' concept. Adding only about 6
or 7 lines to the existing code.
Also, I attempted to implement a way to save the node chats to
disk (as per the SysOps option, check RCHAT300.MRG in the comments
for info on how to turn this option on.. I didn't wanna screw
around with CONFIG) I took the following ideas into consideration:
1: Each chat should have its own unique filename.
-OR, 1a: would one file be okay??
2: One node should write the chat to disk to make sure that
the text is saved in correct order. And this also keeps
the entire chat in the same file.
-OR, 2a: would it be okay if each node:
a: opened the chat file (in file-locked mode)
b: appended its text to the end
c: closed the chat file
for EACH line typed by EACH node?
3: Users are told if the SysOp has told the chat mods to save the
chat to a file.
Problem with above??:
---------------------
Anyways, Using my ideas (1, 1a, 2 and 2a) there are lots of
problems to consider.. not being a great programmer I might
have missed some brilliant idea, but these are problems I see
with the above:
Ideas 1a and 2a would work fine together, but how would we know
where one chat starts and/or ends? or does it matter?
Ideas 1 and 2a present another problem, how would each node
know the unique filename for that chat?
There are more problems, just give it a little thought.
I chose to implement ideas 1 and 2 in this fashion: The node
that initiates the chat (in this case one node pages another)
saves the chat to disk using a unique filename (using time and
date info). If another user joins in, that node realizes it has
not paged, and does try to save anything to disk. What happens
when nodes are 'squelched'?
Maybe, each chat should have a 'process number' which identifies
the chat as unique.
Actually, I'm not going to say: "This is how it works, so live
with it!" I'd rather get input from every SysOp who wants to
contribute and then proceed from there. How should the above
ideas be worked out?
In the end, I think that I'll plan each chat as a separate
'process'. Each process has its own unique name or number, and
then the chats will be saved according to process number.
08/28/90 Heavily modified the chat code. All chats are now character by
3.00 character. This works fine even with multiple nodes. A TrueChat
is now considered a private chat between two nodes, and does
not have its own separate subroutine. The mod now uses a menu
system instead of using separate Ctrl-x sequences for each
'command' You now type 'Ctrl-Q or ESCape' to get the chat menu,
and a chat command prompt, and you can then page someone, see
who is on, etc, from the prompt. To exit back into Chat, you
simply type C (for Chat) or [ENTER]. The W)hos on section was
rewritten to tell the user what the other user might be doing.
For instance, a user might be in Doors, or may be in the message
system, or in the file system. Whos on will now tell them. If the
user sees a CITY after the other users name, they are likely
to be able to page them. The file number used by RCHAT300 was
changed to 9, becuase I failed to realize that file 7 was used
by the voice board driver.
Revision numbers for RBBS Chat mods.
------------------------------------
Revision numbers are as follows: x.yz
x gets incremented when code is added
or heavily modified.
y gets incremented on a major bug fix
release
z gets incremented on a minor fix
End of RBBSChat.doc